[Lattice]IAM認証を利用してOrgnizations内からのみアクセス可能となるようにガードレールを設定してみた

#VPC Lattice

木村優太

2024.02.04

こんにちは、AWS事業部の木村です。

今回もre:Invent 2023の「NET326 Amazon VPC Lattice architecture patterns and best practices」にて紹介されていたIAM認証を利用したガードレールの設定を行なっていきたいと思います。

NET326 Amazon VPC Lattice architecture patterns and best practicesのセッションレポートは以下からご参照ください。

NET326 Amazon VPC Lattice architecture patterns and best practicesで紹介されていた、RAMのカスタマー管理アクセス許可については以下

はじめに

今回はサービスネットワークに対して、IAM認証を設定してOrgnizations内のみからアクセスを行うことができるようにガードレールを設定していきたいと思います。

まずはなぜサービスネットワークに設定を行うかを説明した後に、実際の設定についてやってみたいと思います！

LatticeにおけるIAM認証について

LatticeにおけるIAM認証ですが、サービスネットワークとサービスの両方に設定することができます。

サービスネットワークとサービスのどちらにも設定しておくことができますし、片方のみに配置することもできます。

サービスネットワークとサービスのどちらにも設定した場合、どちらの認証も許可されることで通信が許可されます。

すなわちどちらかの認証に失敗した場合は通信が許可されません。

片方のみに設定した場合は、設定されていない箇所は自動的に全て許可されるため設定したポリシーが許可されれば通信が許可されます。

またIAM認証を行う際はクライアント側でSigV4署名を行う必要があります。詳細については以下をご参照ください。

認証ポリシーを使用してサービスへのアクセスを制御する

IAMポリシーの使い分けに関して

サービスネットワークやサービスに設定するIAM認証はは多層防御の一つであることが述べられておりました。

ですのでそれぞれのに厳密な設定を用いるのではなく使い分けを行うことが重要であり、以下のような区分けを推奨していました。

サービスネットワーク → 全体に必要なポリシーのみを設定し、詳細な認証は行わない。人間にもわかりやすい簡潔なポリシーを推奨する。

サービス　→ サービス毎に必要な詳細なポリシーを設定する。

これはサービスネットワークには複数のサービスが紐づくことが想定されているため、ここで細かい制御を行なってしまうとサービス毎に許可が必要になり複雑で管理しにくいポリシーになってしまうからです。

ですので、使い分けとして細かい制御が要求される際にはサービス側に設定を行いサービスネットワークでは組織として守るべきガードレールのみを設定しておきましょうということでした。

ということで今回は組織として守るべきガードレールを設定していきますので、サービスネットワークにIAM認証を設定していきたいと思います。

やってみる

ではここからは実際に設定を行なって試していきたいと思います。

今回は以下の構成を作成して、組織内のアカウントに所属するリソースのみアクセスが可能な状態にできるように設定していきます。

今回Lattice全般の作成手順は省略いたします。

クロスアカウントにおけるサービスネットワーク、サービス、ターゲットグループ、RAMの作成については以下をご参照ください。

IAM認証を設定する

ではIAM認証を設定していきたいと思います。

既存のサービスネットワークに追加する場合は対象のサービスネットワークを選択したのちに画面右上のアクションボタンから「アクセス設定を編集」を選択してください。

アクセス設定を編集の画面に遷移したら、IAM認証を選択します。

今回Orgnizations内からのアクセス許可するように設定したいので、以下ポリシーを設定します。は適宜置き換えてください。

{
    "Statement": {
        "Effect": "Allow",
        "Principal": "*",
        "Resource": "*",
        "Action": "vpc-lattice-svcs:Invoke",
        "Condition": {
            "StringEquals": {
                "aws:SourceOrgID": "<Organizations>"
            }
        }
    }
}

設定が行えたら、変更内容を保存します。

新規の作成画面から設定を行う場合には、ネットワークアクセスの項目から設定を行うことができます。設定内容としては既存の設定変更と同じ内容で設定が行えます。

実際に通信してみる

まずOrganizations内にあるアカウントBから通信を行ってみます。

ターゲットグループに設定しているリソースからは、通信が成功した場合は「Lattice Success!」と表示されるように設定しています。

ではアクセスしてみたいと思います。今回はSigV4署名が必要な方式となりますのでSigV4署名を行ってアクセスします。設定方法の詳細は以下をご参照ください。

実行するリソースにLatticeのInvoke権限を付与した上で、SigV4署名をつけてアクセスする以下のようなpythonファイルを作成してアクセスします。

from botocore.auth import SigV4Auth
import requests 
from botocore.awsrequest import AWSRequest
from botocore.credentials import Credentials
import botocore.session

if __name__ == '__main__':
    session = botocore.session.Session()
    sigv4 = SigV4Auth(session.get_credentials(), 'vpc-lattice-svcs', 'ap-northeast-1')
    endpoint = 'https://<サービスのドメイン>'
    data = None
    headers = {'Content-Type': 'application/json'}
    request = AWSRequest(method='POST', url=endpoint, data=data, headers=headers)
    request.context["payload_signing_enabled"] = False # payload signing is not supported
    sigv4.add_auth(request)
    
    prepped = request.prepare()
    
    response = requests.post(prepped.url, headers=prepped.headers, data=data)

    print(response.text)

実行したところ以下の結果が出力されました。

"Lattice Success!"

組織内からは無事アクセスができることが確認できました。

続いてOrganizations外にあるアカウントCから通信を行ってみます。

条件は先ほどと揃えてリソースにLatticeのInvoke権限を付与した上で、SigV4署名をつけてアクセスする同様のようなpythonファイルを作成してアクセスしてみます。

AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/role/i-XXXXXXXXXXXXXX is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:ap-northeast-1:012345678901:service/svc-XXXXXXXXXXXXXX/ because no network-based policy allows the vpc-lattice-svcs:Invoke action

こちらは想定通りアクセスをブロックすることができました！